chore(i18n): remove out-of-scope language variants (fixes #1371) #1389
+292,941
−349,745
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently translated at 0.1% (3 of 4121 strings) Translation: eventyay/Eventyay Tickets Translate-URL: https://hosted.weblate.org/projects/open-event/eventyay-tickets/zh_Hant/
Currently translated at 0.2% (9 of 4121 strings) Translation: eventyay/Eventyay Tickets Translate-URL: https://hosted.weblate.org/projects/open-event/eventyay-tickets/zh_Hant/
Currently translated at 0.4% (18 of 4121 strings) Translation: eventyay/Eventyay Tickets Translate-URL: https://hosted.weblate.org/projects/open-event/eventyay-tickets/pl_INFORMAL/
Currently translated at 2.9% (123 of 4121 strings) Translation: eventyay/eventyay Translate-URL: https://hosted.weblate.org/projects/eventyay/eventyay/zh_Hant/
Currently translated at 2.9% (123 of 4121 strings) Translation: eventyay/eventyay Translate-URL: https://hosted.weblate.org/projects/eventyay/eventyay/zh_Hant/
The issue was caused by unconditional access to test_form.cleaned_data without checking if the form validation succeeded. When test_form.is_valid() returned False, accessing cleaned_data could raise AttributeError or return incomplete data, causing a 500 error. Solution: Added conditional check to only access cleaned_data when form is valid, otherwise use empty dict for initial values. This ensures the export page loads properly even when no valid GET parameters are provided. Changes: - Modified ExportMixin.exporters property in control/views/orders.py - Added validation check before accessing test_form.cleaned_data - Fallback to empty dict when form is invalid
Applied the same fix from issueto the organizer-level export
functionality. The ExportMixin in organizer.py had the identical issue
where test_form.cleaned_data was accessed without checking if the form
validation succeeded first.
This prevents potential HTTP 500 errors when accessing:
- /control/organizer/{organizer}/export/
Changes:
- Modified ExportMixin.exporters in control/views/organizer.py
- Added validation check before accessing test_form.cleaned_data
- Fallback to empty dict when form is invalid
- Use f-strings instead of string concatenation for better readability - Rename 'id' variable to 'identifier' to avoid shadowing builtin - Apply improvements to both orders.py and organizer.py Addresses Sourcery suggestions...
- Add JSON_FIELD_AVAILABLE setting based on database backend (postgresql = True) - Fix checkinlists exporter using old Event.items instead of Event.products - Resolves AttributeError when accessing export functionality
- Changed from if/else validation check to getattr() to preserve partial cleaned_data - This allows useful defaults even when form is partially invalid - Reverted unnecessary 'id' to 'identifier' rename in organizer.py - Renamed 'items' field to 'products' in checkinlists exporter for consistency - Updated form_data['items'] to form_data['products'] reference
…fossasia#1157) * Fix navigation button border radius inconsistency - Added border-radius: 0 to .header-nav class in orga/_layout.css - Makes Talk component navigation buttons match Tickets component style - Ensures consistent sharp corners across all navigation buttons - Maintains visual consistency throughout the platform Fixes fossasia#1156 * Add inset shadow on hover to match Tickets component - Added hover and active states with inset box-shadow - Matches the hover effect from btn-success in Tickets component - Uses rgba(0, 128, 0, 0.25) for green inset shadow * Fix navigation button active state to match Tickets component - Added .header-nav.active state with proper inset shadow - Fixed depth and consistency of hover, active, and current page states - Current page button now has same darker border effect as Tickets - All navigation buttons now have identical visual feedback * Improve CSS: use variables and remove important declarations * Fix CSS indentation formatting * Update app/eventyay/static/orga/css/_layout.css * Update app/eventyay/static/orga/css/_layout.css * Fix navigation buttons: sharp corners and inset shadow to match Tickets component --------- Co-authored-by: Mario Behling <mb@mariobehling.de>
Contributor
Reviewer's guide (collapsed on small PRs)Reviewer's GuideRemoves out-of-scope or duplicate locale variants from both frontend (moment.js locale list) and backend (supported locales lists) to align available languages with the intended i18n scope and keep only supported variants like pt-br. Flow diagram for locale validation with updated language listsgraph TD
A[Admin opens admin config page] --> B[Frontend loads momentLocaleSet]
B --> C[Admin opens language dropdown]
C --> D[Admin selects locale]
D --> E{Locale in momentLocaleSet?}
E -- No --> F[Locale not selectable in UI]
E -- Yes --> G[Send selected locale to backend]
G --> H[Backend checks locale in supported_locales_list]
H --> I{Locale in supported_locales_list?}
I -- No --> J[Return validation error]
I -- Yes --> K[Save configuration]
subgraph Frontend
B
C
D
E
F
end
subgraph Backend
H
I
J
K
end
File-Level Changes
Assessment against linked issues
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- The same locale list now exists in three places (frontend
main.vue,helpers/i18n.py, andorga/utils/i18n.py); consider centralizing this into a single source of truth and importing/consuming it in each layer to avoid future drift. - In
main.vue, the comment about using a static moment locale list might be updated or expanded to reference the shared i18n source (if you centralize it), so future changes to supported locales are less likely to miss the frontend.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The same locale list now exists in three places (frontend `main.vue`, `helpers/i18n.py`, and `orga/utils/i18n.py`); consider centralizing this into a single source of truth and importing/consuming it in each layer to avoid future drift.
- In `main.vue`, the comment about using a static moment locale list might be updated or expanded to reference the shared i18n source (if you centralize it), so future changes to supported locales are less likely to miss the frontend.
## Individual Comments
### Comment 1
<location> `app/eventyay/webapp/src/views/admin/config/main.vue:55-56` </location>
<code_context>
- 'mn', 'mr', 'ms', 'ms-my', 'mt', 'my', 'nb', 'ne', 'nl', 'nl-be', 'nn', 'oc-lnc', 'pa-in', 'pl', 'pt', 'pt-br',
- 'ro', 'ru', 'sd', 'se', 'si', 'sk', 'sl', 'sq', 'sr', 'sr-cyrl', 'ss', 'sv', 'sw', 'ta', 'te', 'tet',
- 'tg', 'th', 'tk', 'tl-ph', 'tlh', 'tr', 'tzl', 'tzm', 'tzm-latn', 'ug-cn', 'uk', 'ur', 'uz', 'uz-latn', 'vi',
+ 'mn', 'mr', 'ms', 'ms-my', 'mt', 'my', 'nb', 'ne', 'nl', 'nn', 'pa-in', 'pl', 'pt-br',
+ 'ro', 'ru', 'sd', 'se', 'si', 'sl', 'sq', 'sr', 'sr-cyrl', 'ss', 'sv', 'sw', 'ta', 'te', 'tet',
+ 'tg', 'th', 'tk', 'tl-ph', 'tlh', 'tr', 'tzl', 'tzm', 'ug-cn', 'uk', 'ur', 'uz', 'vi',
'x-pseudo', 'yo', 'zh-cn', 'zh-hk', 'zh-mo', 'zh-tw',
</code_context>
<issue_to_address>
**issue (bug_risk):** Consider whether dropping locales like `pt` and `sk` is expected in the UI and if any stored config values rely on them.
Since `pt`, `sk`, and other locales are being removed from `momentLocaleSet`, any existing config or persisted settings using those codes may no longer resolve correctly and could fall back to defaults. Please verify whether these locales are used in stored data and, if so, ensure a migration or mapping strategy (e.g., `pt` → `pt-br`) so settings don’t end up in an invalid state.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+55
to
+56
| 'mn', 'mr', 'ms', 'ms-my', 'mt', 'my', 'nb', 'ne', 'nl', 'nn', 'pa-in', 'pl', 'pt-br', | ||
| 'ro', 'ru', 'sd', 'se', 'si', 'sl', 'sq', 'sr', 'sr-cyrl', 'ss', 'sv', 'sw', 'ta', 'te', 'tet', |
Contributor
There was a problem hiding this comment.
issue (bug_risk): Consider whether dropping locales like pt and sk is expected in the UI and if any stored config values rely on them.
Since pt, sk, and other locales are being removed from momentLocaleSet, any existing config or persisted settings using those codes may no longer resolve correctly and could fall back to defaults. Please verify whether these locales are used in stored data and, if so, ensure a migration or mapping strategy (e.g., pt → pt-br) so settings don’t end up in an invalid state.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR removes out-of-scope and duplicate language variants from i18n configuration files to align with supported locales. The changes clean up language codes that are redundant or outside the project's scope while preserving the correctly specified locale for Portuguese (Brazil).
Key changes:
- Removed 7 language codes from frontend moment.js locale configuration
- Removed 5 language codes from backend Python i18n helpers
- Maintained consistency across all three configuration files
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| app/eventyay/webapp/src/views/admin/config/main.vue | Updated frontend moment.js locale list by removing 'bn', 'nl-be', 'sk', 'pt', 'gom-latn', 'oc-lnc', 'tzm-latn', and 'uz-latn' |
| app/eventyay/orga/utils/i18n.py | Removed 'bn', 'sk', 'pt', and 'tzm-latn' from backend moment_locales set |
| app/eventyay/helpers/i18n.py | Removed 'bn', 'sk', 'pt', and 'tzm-latn' from backend moment_locales set |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
i18n(translations): update localized strings from Weblate
Member
|
Thanks. Could you please add a screenshot of the language selection option and remove the translation files? |
…speaker-acceptance-link-oof Fix Speaker Acceptance Confirmation Link Returning 500 Error
* fix(translations): Add missing languages * add(translation): Change language selection to drop down from check-box * fix(translation): Add changes suggested by ai comments * fix(translation): Updated Ukrainian to use the standard Django code `uk` --------- Co-authored-by: Mario Behling <mb@mariobehling.de>
…4.* (fossasia#1401) Updates the requirements on [beautifulsoup4](https://www.crummy.com/software/BeautifulSoup/bs4/) to permit the latest version. --- updated-dependencies: - dependency-name: beautifulsoup4 dependency-version: 4.14.3 dependency-type: direct:production ... Signed-off-by: Mario Behling <mb@mariobehling.de>
…sia#1400) Updates the requirements on [celery](https://github.com/celery/celery) to permit the latest version. - [Release notes](https://github.com/celery/celery/releases) - [Changelog](https://github.com/celery/celery/blob/main/Changelog.rst) - [Commits](celery/celery@v5.4.0rc1...v5.6.0) --- updated-dependencies: - dependency-name: celery dependency-version: 5.6.0 dependency-type: direct:production ... Signed-off-by: Mario Behling <mb@mariobehling.de>
…rder (fossasia#1375) Co-authored-by: Mario Behling <mb@mariobehling.de>
Author
|
Hi @Sak1012 @mariobehling |
mariobehling
requested changes
Dec 4, 2025
Member
mariobehling
left a comment
mariobehling
left a comment
There was a problem hiding this comment.
Please change as follows:
- Please remove information like "inofficial translation" or "translation in progress"
- Brazilian Portuguese should be Portoguese (Brazil)
- Finnish and Polish should be sorted alphabetically into the list
- Malay should be there only once
- German should be in the alphabetical list
- However "English" should stay on top as the default
Author
|
Hi @mariobehling, I have updated the language list as requested: Removed “inofficial translation” / “translation in progress” Screenshot Please review and let me know if further adjustments are needed. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1371
This PR removes out-of-scope or duplicate language variants from the frontend and backend language lists.
Removed:
Kept:
Files updated:
No translation
.pofiles were touched, since these appear auto-generated.If needed, I can create a follow-up PR to clean translation folders after confirmation.
All changes validated and build/lint checks pass locally.
Summary by Sourcery
Prune unsupported or duplicate language variants from the application’s configured locale lists to align frontend and backend i18n settings.
Enhancements:
Screenshot
Here is the language selection dropdown after the update:
